The present invention generally relates to file management. More specifically, the present invention relates to enhancing availability of VSAM files.
A large number of companies continue to utilize mainframe systems within their information technology or computing infrastructures. The continuing existence of mainframe systems may be attributed to a number of factors. For example, the pervasive entrenchment of mainframe systems before the advent of client/server computing architecture makes it difficult to completely eliminate use of mainframe systems. Furthermore, in certain respects, mainframe systems are more efficient and cost-effective. For instance, mainframe systems, in general, are better equipped to handle batch processing and data processing intensive applications.
One common file management system that is used in connection with a mainframe system is called Virtual Storage Access Method (VSAM). VSAM is a system available from International Business Machines Corp. (IBM). Using VSAM, a company can create and access records in a file in the sequential order that they were entered. Each record can also be saved and accessed with a key, such as, the name of an employee.
In order to access and manage VSAM files online, an online transaction processing program (OTPP) is typically used. One such OTPP is called Customer Information Control System (CICS) which is also available from IBM. Generally, online regions or systems having capabilities to handle VSAM files online operate in the following manner. The online regions read and/or update the VSAM files throughout the course of a business day. At the end of the day, batch procedures are executed to process the data collected during the day. One of the outputs of this batch processing is updated information to be placed on the VSAM files to be used for the next business day.
Because a VSAM file needs to be closed to the online regions while it is being loaded, how each online region goes about getting the updated information into the VSAM files depends on the volume of information and a given online region's availability requirements. A number of approaches are generally used to update the VSAM files. In one approach, the VSAM files that are to be updated are completely closed to the online regions. Batch processes are then run directly against the closed VSAM files. Once the batch processes are completed, the updated VSAM files are made available to the online regions again. This method leaves the VSAM files unavailable to the online regions for the entire duration of the batch processes, which could potentially mean hours of unavailability.
In a second approach, a batch process is executed to build sequential files of data to be loaded into the VSAM files. The VSAM files that are to be updated are then closed to the online regions. The closed VSAM files are then loaded or updated from the sequential files. The updated VSAM files are then reopened to the online regions. This approach provides relatively higher availability than the approach mentioned above, since the VSAM files are only closed while the loads or updates run.
In a third approach, a batch process is executed to load the updated information directly to a second set of VSAM files. The VSAM files that are to be updated are then closed to the online regions. The original VSAM files and the second set of VSAM files are then renamed. The purpose of the rename process is to switch the corresponding identities of the VSAM files. By renaming the VSAM files, the second set of VSAM files (now renamed) are now available the online regions. As a result, the amount of unavailable time is reduced.
FIG. 1 is a simplified block diagram illustrating the conventional input/output process of an online region for accessing a file. As shown in FIG. 1, a workstation 20 interacts with an application program 22 within an online region to request the application program 22 to retrieve a specific record from a file 28. In turn, the application program 22 asks a file control module 24 to identify the file control table 26 that has information on the file 28 containing the desired record. The file control module 24 locates the file control table 26 and uses information from the file control table 26 to read the desired record from the file 28. The file control module 24 then returns the desired record to the application program 22 which, then, relays the desired record to the workstation 20.
FIG. 2 is a simplified flow diagram illustrating the third approach in more detail. Referring to FIG. 2, it should be understood that VSAM terminology are being used in connection with FIG. 2. A 1/2/3 naming standard is used, referring to a single character within the dataset name of the VSAM file. The ‘1’ file is the dataset that is available to the online regions throughout the business day, i.e., the file that has the designation or name ‘1’ is the dataset that is available to the online regions. The ‘2’ file is the one that the batch process rebuilds with the updated information at night. During the rename process, the original ‘1’ file is renamed to ‘3’ to free up the ‘1’ dataset name for the subsequent rename. All rename operations may be performed with the standard IBM VSAM utility program IDCAMS.
As illustrated in FIG. 2, at 1010, the ‘1’ file is accessible to the online regions during a business day. At 1020, in preparation for the rename operation, the current ‘1’ file is closed to the online regions after the ‘2’ file has been built with updated information. At 1030, the ‘1’ file is renamed to ‘3’ to free up the ‘1’ dataset name. At 1040, the ‘2’ file is renamed to ‘1’ thereby making it accessible to the online regions for the upcoming business day. At 1050, the ‘3’ file (which is the original ‘1’ file before it was renamed) is renamed to ‘2’ thereby making this file available for the batch process to build the ‘2’ file with updated information during the next cycle. At 1060, the ‘1’ file (which is the original ‘2’ file before it was renamed) is opened and made accessible to the online regions.
As described above, the conventional approaches currently used to update VSAM files still require a certain amount of downtime or unavailability time. Hence, it would be desirable to provide a method and system that is capable of further enhancing availability of VSAM files.